Learnings

Outcomes

The outcomes of the project are as follows;

• A coordinated solution to mitigate conflict between balancing and ANM services has been developed and documented. 
• A proof of concept solution has been demonstrated during a trial comprising scenario driven tests to validate the ANM operation during the ESO and ANM service conflicts.
• 20 scenarios were tested under the following categories:

 - Service Conflicts: Demonstrating conflict of services where the ANM degrades the ESO request.

- ESO Decrementing Service Requests: Demonstrating successful resolution of conflict

- Management of Boundary Export: Demonstrating management of conflict & continued management of conflict during the duration of ESO service requests. 

- Constraint Management: Demonstrating successful resolution of conflict under when different constraints are active.

-Response to Failures: Demonstration resolution of conflict under different failure scenarios.

- Principle of Access: Demonstrating resolution of conflict under different ANM principles of access.

• The system was seen to operate correctly with “Hold Mode” preventing ANM generations from increasing their export when other generations are providing ESO Balancing Mechanism instructed generation turndown services.
• The learning from the project has been shared via a dissemination webinar and closedown report. 

Lessons Learnt

Data Quality and Availability

The project had hoped to use data that was not normally used within the business for the commercial evaluation report. The lack of certain data items and the difficulty in determining the context for any customer constraint periods became apparent as the work progressed. The project learned that the following data items were not available:

• Historic levels of headroom created by the ESO’s balancing service decrement requests
• Historic export prices
• Historic levels of curtailment
• Flexibility procurement prices
• Exceeded Capacity Price 

Similarly the curtailable load and position in the Last-in-First-Out (LIFO) stack for each relevant generator was more difficult to obtain than was anticipated as this is not data that has been shared before It is expected that some of this data will be collected in the future to meet the Access SCR changes.

Specification & Design

Data Mapping: During the implementation a potential complexity around data mapping was identified where the unique identifiers for generation and load assets used by the ESO would likely differ from those used by the DNO. As such a mapping layer would need to be implemented somewhere on the system, initial designs discussed an independent “Data Platform” which could be a suitable place for this mapping to occur.

Signal Exchange: There was difficulty around the mechanism of communicating Bid Offer Acceptance Instruction (BOAi) / Physical Notification (PN) between ESO & DSO – operational protocols such as ICCP make this type of data transfer difficult. The use of web services to exchange data was explored, however, early in the design stage it was clear that the required information wasn’t available through web services in neither the ESO nor the DNO operational environments. For purpose of demonstration, ICCP conformance block 4 (InformationMessages) was used to transmit messages in text format but this block is not widely supported / utilised in control systems and as such may not be practical in an operational context. 

Deployment & Test

Due to time constraints the Factory Acceptance Tests were not witnessed by the wider project team. It would have benefited the project to have had representation from all partners witness Factory Acceptance Testing. The project had many nuances, and the documented test script alone was not a substitute for the project team to having the opportunity to see SGS’s product “in action” and ask questions to the SMEs.

Trial 

Service Degradation Due to Ramping: Some degradation of ESO service due to Balancing Mechanism Unit (BMU) ramp down occurring before the hold mode ends. The system implementing the hold mode ideally should initiate hold mode when the BMU starts ramp down, not at the BOA start time, but this requires knowledge of BMU ramp rate / start time. Two solutions are possible for this: 

• Exchange a larger volume of information such as generator ramp rate and expected start time. The ESO holds operational data for each registered BMU including ramp up and ramp down within the Balancing Mechanism (BM) system. When the BM instructs a BMU to be at a set power level at a specified time the BOA instruction issued by the ESO has accounted for the BMUs power ramp rates. 
• If the only information exchanged is a binary on/off hold mode signal then it must be applied at start of generator ramp down. This may have further implications on other methods of solving this conflict of services.

Reduction of Curtailment Events: Hold mode can help reduce control actions on ANM controlled Distributed Generation (DG) when an embedded BMU ramps up after providing a BM service.